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Abstract 


This  report  is  a  review  of  the  issues  related  to  the  establishment  and 
management  of  a  European  Software  Development  Centre  that  has  a 
foreign  founder. 

The  report  contains  53  pages  and  6  exhibits. 
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Introduction 


This  report  is  produced  as  the  result  of  a  bench-mark  in  the  form  of  a 
series  of  meetings  that  have  taken  place  between  Rank  Xerox  and  other 
companies  that  have  been  facilitated  by  INPUT. 

The  structure  of  most  of  these  meetings  has  been  roughly  in  accordance 
with  the  list  of  topics  shown  in  Appendix  G,  in  the  fonn  of  a  questicn- 
natre.  The  meetings  have  been  documented  by  INPUT,  and  the  minutes 
saee  pmmxed  in  the  Appendixes  of  the  report 

Based  iri>oo  the  responses  of  the  ca-ganisations  ccmtacted,  and  seme  yom 

of  industry  experience,  INPUT  summarised  these  meetings,  and  made 
conclusions  that  form  the  main  body  of  the  report. 

The  pnpose  of  the  beneh-nsak  has  been  to  learn  and  understand  the 
experiences  of  similar  organisations — that  is,  European  Software  Devel- 
opment Centres  with  a  foreign  founding  organisation. 

The  methods  adhered  to  have  been  consistent  with  the  bench-mark 
principles  included  in  Xerox'  Leadership  through  Quality  process. 

INPUT  believes  a  number  of  significant  coQclu^ons  have  been  reached 
that  could  provide  long-term  benefits  to  the  successful  growUi  of  the 
Eiu-opean  Software  Development  Centre. 
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Executive  Overview 


This  report  is  produced  as  a  result  of  a  series  of  meetings  between  Rank 
Xerox  and  six  other  companies  of  non-U .K.  origin  that  were  selected  as 
having  European  Software  Devdcpoent  Cnures.  Ri^  Xesox  and  m 
companies  aie  i^own  in  Exhibit  11- 1,  along  with  ikek  locaticms  and 
origins. 

EXHIBIT  11-1 


Bench-mark  Participants 


Company 

Origin 

European  Location 

Andersen  Software 

U.S. 

Sophia,  Valbonne,  Frai)o& 

Bell  Northern  Research 

Canada 

Maidenhe^,  Berths.,  U.K. 

Digital  Equipment  Co. 

U.S. 

Reading,  Berks.,  U.K. 

Hewlett-Packard 

U.S. 

Wokingham,  Berks.,  U.K. 

Prime 

U.S. 

Milton  Keynes,  Bucks.,  U.K. 

Rank  Xerox 

U.S. 

Welwyn  Garden  City,  Herts. 

Siemens 

Germany 

Woodley,  Berks.,  U.K. 

Discussions  were  based  on  the  following  three  main  topics: 

•  The  benefits  of  a  European  Software  Development  Centre 

•  The  internal  organisation  of  a  European  Software  Development  Centre 

•  The  interactions  of  a  European  Software  Devek^ment  Centre  wifli 
othex  parts  of  the  (S'ganisation 
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The  tcpoTt  contains  a  summary  of  the  main  points  that  were  gleaned  firom 
tte  meetings  and  an  assessment  of  the  key  lessons  to  be  learned  from 
each  of  tlw  other  organisations. 

The  report  identifies  that  the  organisational  aspects  were  considered  of 
greater  importance  than  the  technical  ones,  and  arrives  at  a  set  of  five 
critical  ^access  fiitctc»s  for  the  Effective  naanagemoat  of  the  Einx^iean 
Software  Develofaiient  Centre. 

finns  sci«:ess  hcttm  are: 

•  Having  two  strong  champions  committed  to  the  centre's  success,  one  in 
the  founding  organisation,  and  one  being  the  manager  of  the  centre 
itself 

•  Ownership  of  a  mainline  product  or  programme  with  worldwide 
responsibility 

•  A  strong  emphasis  on  interfaces  and  communications  with  other  parts 
of  the  company,  especially  the  founding  development  organisation 

•  A  correct  balance  between  giving  Ae  EHSQpBaD  So&warQ  Developmwit 
Centre  a  high  degree  of  autonomy,  and  the  need  to  provide  strategic 
direction  from  an  overall  company  point  of  view 

•  A  correct  balance  between  supporting  the  founding  development 
organisation,  and  supporting  die  local  sales  and  marketing  organisation 

INPUT  arrived  at  these  ccMOclusions  by  talking  to  similar  companies  with 
similar  problems  at  different  stages  of  development  and  believes  that  if 
these  conclusions  are  taken  into  careful  consideration,  significant  mis- 
takes ia  tiie  planning  of  the  c^^um-  to  long-term  fttttne  of  the  European 
Sk^wase  Devd.qpmait  Ceaitre  will  be  avmded. 
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Bench-mark  Diary 


14  February,  1990:  Meeting  between  Rank  Xerox  and  INPUT 

6  March,  1990:  Meeting  between  Hewlett-Packard  and  INPUT 

Minutes  of  the  following  meetings  are  provided  as  appendixes  in  this 
report: 

20  April,  1990:  Mating  b^een  Rank  Xoox,  Hewlett-Packard  aiMi 
INPUT 

2  May,  1990:  Meeting  between  Rank  X^x,  Prime  and  INPUT 

8  May,  1990:  Meeting  between  Rank  Xerox,  DEC  and  INPUT 

14  May,  1990:  Meeting  between  Rank  Xerox,  Andersen  Software  and 
INPUT 

23  May,  1990:  Meeting  between  Rank  Xerox,  Siemens  and  INPUT 

1 1  June,  1990:  Meeting  between  Rank  Xerox,  Bell  Northern  Research 
and  INPUT 

Minutes  from  the  following  meeting  are  a  separate  document  and  will  be 
circulated  to  all  the  participants,  as  well  as  Siemens,  which  was  unable  to 
at^«}  but  wishes  to  be  associated  with  the  poup's  activities. 

15  June,  1990:  Meeting  between  Rank  Xerox,  Andersen  Software,  Bell 
Northern  Res^?ch,  Digital,  Hewlett-Packard  and  Prime 
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Summary  of  Meetings 


This  section  of  the  report  summarises  the  major  points  that  have  arisen 
out  of  all  the  meetings,  and  identifies  the  trends  that  are  common  to  most 
of  the  oigamsaticms  ccmtacted. 


Interfaces  with  the 
Founder  Organisation 


EXWBIT IV-1 


One  of  the  most  significant  issues,  if  not  the  most  significant,  is  the 
int&fytce  with  the  founder  organisation. 

Setting  up  any  new  organisation  presents  a  significant  management 
cbaEmfe,  Ixtt  dcnng  it  to  a  foreign  country  clearly  exacerbates  this 
ciuiQ^ge.  Exhibit  IV-1  summarises  thea^ticmalisc^lems  that  arise  for 
a  number  of  straightfcKrwaid  reasons  but  can  omtribute  to  major  di^icul- 
ties: 


Communications  Problems  witli 
Foreign  Founder  Organisations 

•  Lack  of  informal  communications 

•  Parent/child  relationship 

•  l.^ck  of  credibility 

•  National  cultural  differences 

•  Cultural  differences  related  to  oi^sanisation 
size 
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•  Lack  of  informal  c(»iimuiucati(His  that  normally  aid  the  workings  of  an 
organisation 

•  A  tendency  to  devtAop  a  puent-child  rather  than  an  adult-adult  rela- 
tionship 

•  A  mutual  lack  of  credibility  due  to  lack  of  track  record 

•  National  cultural  differences 

•  (Mtural  differences  by  virtue  of  diffoimt  organisation  sizes 

Failure  to  solve  these  problems  will  typically  lead  to  poor  motivation, 
and  diQD^ore      niifiO^  <^  Stiff, 

The  result  is  an  inai^iangiy  vicious  circle  CTOsc^cmes  tiie  at^bili^ 
problem. 


Exhibit  IV-2  summarises  the  solutions  to  ttese  problem,  wbicdi  are 
varied  but  typically  include: 


Soiutioim  to  Communication  Probiems 

•  Circulation  of  people 

•  Enable  eaiiy  credibility 

•  Champions 

•  Technical  facilities 

•  Mutual  toieran(»  and  under^anding 

•  Frequent  meetings 

•  Moving  people  from  parent  to  subsidiary  and  vice  versa  in  order  to 
develc^  weeing  tektionships 

•  Enabling  the  new  organisatkm  to  {u;hieve  early  victcHies  to  establish 
credibility 

•  Having  a  senior  person  in  the  founder  development  argaiusation  to 
champion  the  new  organisation 

•  Having  good  technical  (xcmmunications  facilities 

•  Developing  mutual  understanding  of  cultural  differences 
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Holding  frequent  meetings 

Plaiining  to  make  the  new  organisation  as  autonomous  as  possible  as 
quickly  as  possible 


Project 

Respcmsibilities 


EXHIBIT  IV-3 


liferent  ccm^ames  divide  the  responsibilities  between  development  and 
madcc^gitt  different  ways,  but  it  is  generally  accepted  that  the  develop- 
ment manager  should  have  a  worldwide  responsibility  for  the  product  or 
programme. 

Typically  a  company  will  set  up  a  marketing  organisation  when  it  eaters 
a  new  country  that  has  responsibility  for  activities  in  that  country.  The 
develcpoamt  organisation,  on  the  other  hand,  comes  in  later  and  tends  not 
to  have  cmmtry  responsibility  but  has  product  responsibility  back  to  tihe 
devel(q)mmt  part  of  the  fouiuier  organisation. 

The  responsibility  issue  is  therefore  complex,  muse  tiiere  is  a  to 
mterface  mih  central  development,  central  maricettag,  aiui  the  local 
marketing  organisation,  as  well  as  othm. 

Exhibit  IV-3  smmnarises  certain  trends  tfiat  have  been  detected,  namely: 


Organisational  Trends 

•  Autonomous  business  units 

•  Direct  contact  with  clients 

•  Integration  of  marketing  function  with 
development 

•  Interaction  with  local  onganisation 

•  A  trend  towards  a  business  unit  organisation  where  project  mana^rs 
have  revenue  responsibilities 

•  A  tendency  to  create  direct  contact  with  flie  clients,  which  is  good 
motivationally  and  for  quality 

•  A  tendency  to  integrate  at  least  part  of  the  product  marketing  into  the 
develc^ment  cntganisation 

•  Attrai^ts  to  interact  with  local  country  ma^esimg  organisations  sepa- 
rately from  tl^  founder  developn^nt  co'ganisation 
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A  trend  towards  greater  autonomy  can  also  create  its  own  problems,  such 
as  conflicts  for  product  ownership  between  different  parts  of  the 
organisation. 

There  is  clearly,  therefore,  an  important  role  for  senior  management, 
especially  in  starting  up  projects  and  tackling  the  problem  of  freeing 
resources  to  tackle  new  jnojects. 

Rotation  of  resources  and  encouraging  people  not  to  maintain  too-narrow 
q)ecialisadcms  can  also  impact  this  problem. 

Senior  management  also  has  a  role  in  the  resolution  of  marketing  devel- 
opment conflicts,  typically  over  moving  targets. 


Career  Development 
and  Recruitment 


D 


There  is  a  recognised  problem  in  providing  a  career  path  for  technical 
Staff.  Some  organisations  provide  only  a  management  route;  others 
proviite  a  technical  omsuluincy  route. 

Most  companies  prefer  to  recruit  trainees,  but  this  approach  is  not  always 
pomble  and  experts  scnnetim^  have  be  lx>ught  in.  M  Ae  same  way  it 
can  be  difBcidt  to  grow  manageo^nt  capability. 

Rotating  staff  into  and  out  of  other  parts  of  the  company  and  having  a  set 
procedufe  to  do  so  am  be  an  impc»tant  contribution  to  dus  {»oblem. 


Quality  Issues 


E 


Quality  goals  tend  to  be  associated  wifli  maintenance  and  custcHner 
feedl»ck  in  order  to  assess  satisfaction.  Performance  against  budget  and 
delivery  schedules  aie  also  indications  of  quality. 

Transferring  software  fiom  one  cn-ganisation  to  anotho:  can  be  a  major 
trauma  if  quality  is  not  agreed  upon  and  checked  first  before  the  hand- 
over. Failure  to  agree  and  check  can  greatly  exacerbate  organisation 
problems  and  create  long,  difficult  and  often  emotional  arguments. 


Finance 


Funding  tends  to  be  from  the  founding  development  organisation,  but 
smm  mpai^^&cm  have  a  mmll  proporticm  of  local  cus»»iin:s  ^ch 
also  provide  funding. 

Paying  of  bonuses  can  present  a  problem.  Bonuses  can  be  resented  by 
s(Hne  staff,  aikl  it  is  very  impcatant  to  see  that  bonuses  are  fair.  Fairness 

can  be  a  complex  issue  because  extra  hours  do  not  necessarily  indicate 
higher  performance,  and  bonuses  on  the  basis  of  time  or  budget  are 
dependent  upon  the  quality  of  the  initial  estimates. 
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Assessment  of  Contributing 
Organisations 


Without  going  into  detail,  it  is  possible  to  identify  some  key  strengths  of 
each  of  the  organisations  that  have  contributed  to  the  bench-mark.  A  brief 
ass^iaoD^t  ci  each  organisiokm  is  ccmtamed  in  this  secticst;  overall 
OMiclusicHis  aie  in  the  Overall  Coaclu^CHis. 


Hewlett-Packard 


The  divisional  model  is  a  brilhant  concept  that  Hewlett-Packard  devel- 
oped. Every  diviidon  operal^  as  an  autoncnnoos  business;  evacy  diviskn 
has  a  similar  model  and  woridwide  lespcmsibility.  The  model  is  shown  in 
Exhibit  V-1. 


EXHIBIT  V-1 


Hewlett-Packard  Divisional  Model 


1 


Manufacturing 


I 


Marketing 


Divisional 
General  Manager 


•  Worldwide  product  responsibility 
•Headcount:  120  to  300 

•  Budget  and  revenue  objectives 


I 


Quality  and 
Productivify 


I 


Financial 
Administration 


I 


Research  and 
D^n^opment 


Personnel 


Product 
Marketing 


Learning 
Products 


— T" 

Field 
Training 


On-line 
Support 

Section  1  ^  ^  ^  1  Section 

1            1  1 

1  1 

Project 


Project 


Project 


Project 


■  6  to  1 0  persons 
per  project 


Project 


Section 


per  section. 
20  to  40  persons 
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There  are  six  functions  in  each  division,  although  the  balance  may  be 
different  in  each  one  according  to  circumstances.  The  six  functions  are 
mannfacturing,  peisonnel,  qmkty  and  productivity,  financial  administra- 
tion, marketing,  and  research  and  development.  These  functions  can  be 
shared  with  another  division,  and  occasionally  quality  and  productivity 
are  embedded  elsewhere.  The  size  of  a  division  is  typically  120  -  300 
people  divided  into  sections,  with  3-5  pn^ects  ip&c  section  and  6-10 
enginem  par  project 

The  product  imnager  is  only  the  first  level  Mm  the  boUmi  in  HP- s 
managea^nt  structure,  yet      managor  has  ccMQ3|dete  r^p(Hisil»lity  for  a 
IHXxluct,  including  product  marketing  aiul  revenue  targets. 

The  str^pths  of  this  taodel  are  that  it  is  cnrganic  and  allows  easy  spawn- 
ing erf  new  businesses,  it  reinforces  the  company  culture  since  the  model 
is  always  the  same,  it  delegates  a  great  deal  of  responsibility  and  motiva- 
tion, and  it  makes  intracompany  communication  work  on  a  common 
undorstaiMiing. 

The  key  lesson  for  Rank  Xerox  is  obviously  not  as  a  role  model,  but  to 
recogni^  the  gains  in  fl^ibility,  motivaticm,  ccxmmunicatioai  im^lems, 
and  commitment  frooa  se^g  up  m  OE^uiisaticm  that  is  fiolly  miciQcmious 

and  responsible  for  revenues.  However,  the  consequences  of  this  model 
are  that  it  clearly  requires  a  significant  amount  of  senior  management 
support  mi  tcskmaxst,  and  a  pr^acedness  by  senica-  managm  to  resolve 
conflicts  between  different  divisions.  It  also  requires  a  definite  vision  in 
order  to  ensiu'e  that  all  the  divisions  are  moving  in  the  same  direction. 

A  di^nite  weakness  of  Hewlett-Pa(^kaid*s  apprc^h  is  the  lack  of  a  dual 

career  path  for  technical  as  well  as  managerial  staff.  The  model  com- 
mented upon  above  has  very  few  layers  of  management,  and  the  lack  of  a 
patii  fir  technical  people  exacerbates  tl^  paMem.  HP  has  tskea  the 
attitude  that  it  is  more  economical  to  recruit  trainees  to  a  level  of  compe- 
tence than  to  have  in-house  experts.  HP  may  well  have  to  tackle  this 
career  path  problem  in  the  near  future,  as  Bell  Northern  and  Digital  are 
doing  now. 


Prime  Prime  is  a  very  good  example  of  how  not  to  proceed.  Prime  has  suffered 

significant  problems  as  a  result  of  the  hostile  take-over  attempt  by  MAI 
and  the  J  JL  Whitney  purchase,  and  as  a  result  Prime  has  suffered  redun- 
dancies. 

The  solution  of  the  manager's  spending  one  week  per  month  in  the  States 
is  not  coherent  and  is  not  likely  to  contribute  much  to  a  solution.  People 
from  the  States  should  be  spending  one  week  per  month  in  Milton 
Keynes. 
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It  would  be  more  coherent  for  the  parent  organisation  to  leave  Milton 
Keynes  alone  if  the  policy  was  to  give  greater  autonomy.  It  does  make 
sense  if  Priim  in  die  U.S.  is  still  trying  to  control  Miltcffi  Keynes  strictly. 
In  other  words  Milton  Keynes  is  gating  the  wcarst  of  both  wwlds:  not 
bdng  independent,  and  not  being  supported. 

C   

Digital  Hewlett-Packard.  Due  to  Digital's  matrix  organisation  with  mirror 

miniorganisations  throughout  the  company,  the  level  of  communication 
necessaiy  bdmc  EcmMfig  a  d«dsion  is  frightening.  Jac  Simensen  must 
spend  99.99%  of  his  tinae  in  meetings.  "The  aidvantages  have  clearly  been 
a  set  of  very  coherent  products,  but  the  costs  must  be  frightening. 

Digital  is  dismantling  the  msAe6ng  part  of  the  (vganrntion,  {oobably  as 
a  lesult  of  a  political  decision  after  Jack  Shields'  departure  to  Prime,  but 
the  key  is  that  Digital  recognised  it  will  have  to  devolve  revenue  respon- 
sibility to  the  research  and  development  organisations  in  order  to  slim 
down  and  be  more  efficient.  In  other  words  Digital  is  heading  in  the  same 
direction  as  Hev/lett-Packaid. 

D  

Siemens  A  theme  common  to  others  but  learned  by  Siemens  is  the  importance  crf 

allowing  the  R&D  function  to  have  direct  contact  with  the  customers. 
Also,  Siemens  has  recognised,  much  to  its  cost,  that  it  has  underestimated 
the  cultural  differences  between  tht  U.K.  and  Germany. 

Apart  from  cultural  problems  due  to  national  differences,  about  which 
everybody  has  his  or  hea"  ovwi  opinions,  Siem^s'  major  problems  have 
been  cultural  differences  due  to  interaction  of  different  kinds  <^ 
organisaticms. 

Sien»ns  is  a  small,  iofotmi  osganisation  in  a  shopping  centre  and  inter- 
faces with  an  enormous  organisation  of  35,000  employees.  The  conq>atty 
suffers  from  the  company  culture  clash  between  Nixdorf  and  Siemens, 
one  of  which  is  a  marketing-oriented  company,  and  the  other  an  engineer- 
ing-oriented ccwEptny.  There  has  been  a  total  lack  of  sensitivity  to  these 
probtems,  and  it  will  cost  a  great  deal  of  money. 

E  

Anders^  Software       Andersen  Software  has  gone  through  growing  pains  similar  to  those  of 

everybody  else,  and  there  is  nothing  startling  about  the  conclusions  and 
lessons  learned.  However,  there  is  one  important  lesson  that  can  be 
learned,  or  at  least  appreciated,  about  Andersen  Qmsulting. 

The  company  has  a  very  strong  and  coherent  company  culture  as  a  result 
of  its  employee  induction  process  at  the  Chicago  headquarters.  Andersen 
Omsulting  ^c^oie  hss  a  simlliff  sei    procedor^,  ^sEvifGHua^  and 
tools  all  over  tfie  w<»rld,  which  enables  it  to  provide  a  multinaticHial 
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capability  to  support  clients  that  is  the  envy  of  many  other  professional 
services  organisations.  The  key  is  Andersen's  willingness  to  move 
p^le  around  all  the  time  without  worrying  too  much  about  people's 

specialities.  This  willingness  to  rotate  people  has  come  about  because  of 
the  nature  of  Andersen's  services  business,  but  it  has  also  helped  the 
company  to  set  up  and  grow  product  organisations  very  quickly. 

In  addition  to  the  speed  of  set-up  due  to  the  ready  availability  of  people, 
mobility  has  also  given  Andersen  two  other  key  advantages.  Rotating 
people  into  ai^  out  of  tiie  software  development  organisati<m  maa^  that 
the  consultants  in  the  field  who  are  close  to  the  clients  actually  use  the 
products  and  are  product  salespeople.  Also,  since  the  consultants  under- 
stand the  development  organisation,  they  provide  a  very  high  quality  and 
qusiiti^  oi  feedback  hdkx»  and  aUcr  product  launch,  which  leads  to  a 
better  capture  of  us^  lequixements  and  fas&sr  assessooent  of  product 
quality. 

There  is  clearly  a  pemdty  to  be  paid,  since  it  is  often  difficult  few  a 
company  to  adjust  from  services  to  products  and  vice  versa;  however, 
Andersen's  willingness  to  rotate  people  around  the  organisation  and  to 
expect  them  to  adapt  and  succ^  is  an  in^rtant  lesson. 

F  

Bell  Northern  It  is  difficult  to  gain  any  definite  perception  due  to  a  lack  of  information, 

Research  but  Bdl  MsfAeim  is  vray  expmenced  and  has  reco^lised  the  need  to 

develop  dual  career  paths  for  management  and  tecfanicmns.  How  Bell 
Northem  proposes  to  develop  dual  paths  is  not  ctear. 
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Given  the  major  items  of  discussion  from  each  of  the  meetings  and  a 
brief  assessment  of  each  of  the  organisations  visited,  it  is  possible  to  draw 
overall  ccHK;lttsicHis  that  could  have  a  significant  effect  on  the  manage- 
ment of  a  European  Software  Development  Centre.  The  young 
organisations  and  the  old  organisations  all  show  similar  tendencies,  and 
there  has  been  a  significant  level  of  agreement  on  identifying  the  key 
issues. 

If  Rank  Xerox  can  incorporate  these  lessons  in  its  long-term  vision,  and 
accept  that  tiiese  imasares  wffl  hme  to  be  taken  eventually,  it  may  assist 
in  making  some  of  the  deda^  mcHi^  earlier.  AH  cx^oisatifms  have  to 

go  through  a  learning  process,  but  DvfPUT  believes  some  of  the  material 
in  the  bench-mark  could  make  the  learning  process  less  painful  and  less 
expensive. 

The  overall  conclusion  then,  is  that  there  are  five  critical  success  factors 
for  setting  up  and  successfully  managing  a  European  Software  Develop- 
meat  Cmtm,  and  tbe^  five  fadms  m  utttalinloBd.  The  five  are 
summarised  in  Exhibit  VI- 1,  and  described  below. 


Critical  Success  Factors  for  a 
European  Software  Development  Centre 

•  Two  champions 

•  Msunline  product  ownei^hip 

•  Communications  and  interfaces 

•  Balances  of  autonomy  vs.  strategy 

•  Balance  between  founders 


Overall  Conclusions 


EXHIBIT  VI-1 
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a.  The  European  Software  Development  Centre  needs  two  champi- 
ons— one  in  the  founding  organisation  and  one  in  the  centre.  Two 
chamirimis  are  needed — not  just  to  «ise  communicatimi  b^w^n 
the  two,  although  communication  is  extremely  important — but 
also  as  an  important  role  within  his/her  own  locations. 

The  Centre  needs  a  v&j  jp^ch'  manager  in  the  founc^g  oiganisation 

who  is  committed  to  the  ESDC's  success.  This  champion  can  repre- 
sent the  European  Software  Development  Centre's  views,  problems, 
aiui  ^fllerimt  perspectives  at  strategic  m^tings.  This  chan:^i<:ni  can 
also  T^seixmit  the  centre  for  administration  and  procedures  purposes. 

The  other  champion  is  the  European  Software  Development  Centre's 
mana^.  It  is  in^Ktr^t  tbat  Ms  person  is  not  only  committed  but 

dedicated  to  the  centre's  successful  long-term  implementation,  and 
does  not,  for  example,  take  on  the  job  as  just  another  part  of  his  or  her 
administrative  duties. 

b.  The  European  Software  Development  Centre  must  have  owner- 
ship of  an  important  mainline  product  or  programme,  with 
worldwide  reip(»dbility  for  it. 

Failure  to  recognise  this  need  can  be  very  costly.  The  most  obvious 
benefit  is  the  positive  motivation  of  people  who  have  to  feel  respon- 
sible for  wMt  ibi&y  i^?odu<%,  aiKl  the  challrage  enables  the  c<»itre  to 
develop  very  quickly  in  order  to  provide  full,  high-quality  service.  In 
other  words,  the  centre  becomes  a  centre  of  excellence  much  more 
quickly,  and  is  mote  mcdy  to  retain  Mg^-calibre  people. 

A  less  obvious  reason,  but  no  less  important,  is  that  ownership  of  a 
mainline  product  or  programme  gives  the  centre  a  more  equal  footing 
wilb  the  foninding  organisaticm  aiKl  a  clear  iiK^mtive  to  mirror  the 
foondktg  OfpooisiytkHi's  practises  md  proceduies.  Ownership  pro- 
vides a  more  coherent  organisation  m<ffe  quickly,  and  assists  in 
communication  between  the  two. 

c.  The  European  Software  Development  Centre  must  establish  a 
strong  emphasis  on  interfaces  and  communications  with  other 
parts  of  Hie  company,  especially  with  the  fouiiding  dev^pment 
organisation. 

These  interfaces  are  the  principle  ways  in  which  the  organisation  will 
be  assessed,  and  totratkm  to  the  needs  of  marketing  and  die  local 
sales  cnf anis^ons  is  in^xstant 

The  most  critical  interface  is  clearly  with  the  founding  organisation; 
diis  tepoft  has  sUmiiy  bem  v^esai^Bed  how  two  dumopens  mid  own- 
ership of  a  nmnline  product  can  assist  in  communication.  Although 
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often  difficult  to  cost-justify,  movement  of  people  from  both 
organisations  to  visit  each  other  or  to  work  on  temporary  secondment 
can  have  a  sigmficant  impact  cm  integrating  the  new  centre  into  the 
ovearall  company  quickly  and  efficiently.  Regular  and  effective  com- 
munications— by  teleconferencing,  electronic  mail,  etcetera — are  also 
very  important. 

d.  The  European  Software  Development  Centre  must  achieve  a 
correct  balance  between  a  high  degree  of  autonomy  and  the  need 
for  a  c(riti«*ait  strategic  direotilfiii  from  an  overall  company  point 
of  view. 

This  balance  has  been  touched  on  in  b.  above,  and  the  ownership  of  a 
mainline  {soduct  would  ccmtribute  significantly  to  devolving  an* 
tonmny  to  a  European  Software  Development  Centre.  A  high  level  of 
autonomy  in  an  organisation's  constituent  parts  gives  it  a  tremendous 
fladWlity  to  respond  to  the  needs  of  markets.  Autonomy  also  raables 
parts  of  the  organisation  to  pursue  their  own  goals,  even  to  the  extent 
thsA  there  is  a  healthy  level  of  ccnnpetition  between  these  parts. 

At  the  same  time  there  is  a  definite  need  fc«r  a  high-level  strategy  tfiat 

is  clearly  communicated  in  order  that  the  needs  of  the  company  are 
addressed  as  a  whole,  overall  direction  is  provided  and  key  conflicts 
are  resolved.  This  balance  is  clearly  not  easy  to  achieve  so  that  the 
light  dedsicHis  are  made  at  tbgt  fig^t  levd,  mi.  oxfdiadses  the  in^xn:- 
tanc»  of  ^ecdve  communications  identified  in  c.  above. 

e.  The  European  Software  Development  C&aire  must  adiieve  a 
correct  balance  between  supporting  the  founder  development 
organisatim  and  the  sales  and  marketing  oi^ianisation  in  the  local 
country. 

It  is  important,  in  the  interest  of  autonomy  and  efficiency,  that  the 
software  development  centre  should  support  the  local  sales  and  mar- 
keting organisation.  There  is  a  clear  interest  in  economies  of  scale, 
reduction  in  lines  of  communication,  and  general  suj^KHt. 

At  the  same  time  it  is  critically  important  that  the  company  wide  view 
is  iflK)  maintained.  Hictc  is  a  clear  and  obvious  synergy  between  a 
development  organisation  and  its  founding  development  organisation, 
and  there  is  an  inherent  danger  in  detachment  in  order  to  serve  the 
interest  of  the  geographically  local  organisation.  The  potential  costs  of 
having  different  development  p-actises,  a^  of  not  taldng  advantege  of 
expertise  gained  in  similar  functions  in  othor  geographical  locations, 
are  veiy  high. 
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Appendixes 


Hewlett-Packard 


Structure  of  Meeting 

Hewlett-Packard  representative:  Andy  Wilde 

An  introduction  by  Mike  Henry  on  tiie  concept  of  (»ganisational  b«H;h- 
marking. 

An  introduction  by  each  person  present  at  the  noeeting  on  his  or  her 
personal  history  and  background. 

A  presentation  by  Andy  Wilde  oa  Hewlett-Packard's  internal 
corganisation. 

A  pfesentaticxi  by  Andy  Wilde  on  Hewlett-Packards  Software  Engineer- 
ing Systems  IMvision. 

A  discussion  on  the  responsibilities  of  the  product  manager/chief  engi- 
neer as  a  result  of  Mike  Heiiiy''s  presentation  on  Rank  XiSnox*s  intanal 
(H-^misaticm. 

A  discussion  on  the  next  steps  to  take. 


•  The  principles  of  organisational  bench-marking  were  agreed  upon,  and 
it  w^  also  agie«i  flut  tl»  b^iefit  would  be  in  the  establi^in^  of  a 
l(mg-teim  relaticmship. 

•  The  existing  list  of  topics  was  agreed  to  be  a  very  good  starting  point 
for  the  bench-maik.  (Please  note  that  the  original  list  has  been  modified 
slightly  because  Hewlett-Packard  was  sensitive  about  revealing  its 
lessons  learned.) 


Comments  on 
the  Concept  of 
Oigamsaticm  B^ch- 
majrks 
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•  If  the  bench-mark  were  to  be  simply  a  one-to-one  between  Rank  Xerox 
and  Hewlett-Packard,  HP  would  not  be  interested  in  continuing. 

•  Of  all  the  projected  participants  in  the  organisational  bench-niaik» 
Hewlett-Packard  is  most  sensitive  about  Digital  because  they  arc  very 
closely  matched  rivals. 

B  

Personal  Background    •  Andy  Wilde  joined  ICL  at  Bracknell  over  15  years  ago  and  spent  seven 

andalialf  y^Fs^ddilCLcm  system  software  for  the  2900  series.  He 
also  repres^iedlCLcm  X25.  He  then  spent  18  months  with  Digitalin 
its  office  systems  group  and  left  for  organisational  reasons.  He  has 
been  with  Hewlett-Packard  for  seven  and  a  half  years,  spending  six 
y^rs  in  a  software  engimering  role  as  a  secticm  manager  in  <^ce 
systems.  Eighteen  months  ago  he  moved  to  the  Software  Engineering 
Systems  Division,  which  develops  Hewlett-Packard's  CASE  tools,  to 
set  up  the  European  end  of  a  United  States  division. 

c  

Hewlett-Packard  •  Hewlett-Packard  has  an  organisational  model  that  has  been  developed 

Organisation  with  experience.  Tte  modd  ra»msts  of  four  layers: 

-  Sector 

-  Group 

-  Division 

-  Section 


•  The  key  to  the  concept  is  the  division.  Each  division  operates  as  an 
autonomous  business  with  total  responsibility  for  its  products.  A  model 
of  the  dividon  is  shown  in  Uie  main  body  of  the  report  in  Exhibit  V-1. 

•  A  divisifHial  gena:al  manager  has  worldwide  n^x>nsibility  for  a 
product  area,  a  headcount,  and  a  budget,  and  im  a  revenue  objective  by 
product  (X  business  line. 

•  Each  division  ctxisists  of  6  functions — manufacturing,  pei^nnel, 

quality  and  productivity,  financial  administration,  marketing,  and 
research  and  development.  Some  of  the  functions  within  a  division  may 
be  shared  with  another  division  if  they  share  a  physical  location.  In 
ordee  to  reduce  overhead,  typically  faring  could  involve  persoinel 
and  financial  administration.  Also,  quality  and  productivity  is  some- 
times embedded  elsewhere  in  the  division  rather  than  separate. 

•  The  balance  of  people  within  the  organisation  will  vary  according  to 
the  type  of  business.  For  example,  the  balance  of  R  &  D  and  manufac- 
turing will  be  different  between  software  and  hardware  businesses. 
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•  Typically  each  division  contains  120-300  people  divided  into  sectkms, 
with  3-5  projects  per  section  and  6-10  engineers  per  project 

•  Th«  prodiu^t  manager  is  the  first  level  up  from  the  bottom  in  the  man- 
agement structure,  yet  has  total  responsibility  for  the  product — includ- 
ing product  marketing  and  revenue  targets,  not  just  production. 

•  There  is  a  distinction  between  field  marketing  (which  is  concerned  witili 
sales  within  a  country  market)  and  product  marketing  (which  is  con- 
cerned with  sales  of  that  product  across  markets).  This  separation  is  at  a 
very  hig^  pcnnt  in  die  crganisation,  just  bdow  board  level. 

•  The  divisional  model  is  a  tried  and  tested  concept — ^Hewlett-Packard 
has  96  #«dsicMis  wotids^^,  said  each  divisi<m  has  a  ix^ldwide  r^xm- 
sibility  for  its  bu^oess  area.  A  division  may  set  up  a  separate  opmtion, 
but  this  operation  will  th^  develop  into  a  divisicm  using  the  same 
model. 

•  Hewlett-Packard  has  had  overseas  divisions  with  worldwide  responsi- 
bility for  a  long  time,  and  in  order  to  set  up  the  European  software 
development  centre  at  Pinewood,  HP  sent  people  from  the  United 
Kingdom  to  the  United  States  to  gain  work  expesksacxt,  and  then  when 
HP  set  up  the  organisation,  one  or  two  key  people  from  the  United 
States  came  to  the  U.K.  to  get  it  off  the  ground. 

•  Hewlett-Packard  has  more  than  7,500  people  in  research  and  develop- 
ment with  an  annual  expenditure  of  $1.5  billion,  75%  of  which  is  spent 
on  software  development. 

•  As  a  corporate  objective,  Hewlett-Packard  aims  to  irapxovc  its  quality 
tenfold,  and  double  its  productivity  every  5  years. 

D  

The  Software  •  The  divisional  manage  is  Chuck  House,  and  the  marketing  is  run  by 

Engineering  Systems      Gail  Hamilton. 

Division 

•  Asa  i^ategic  part  of  HP's  survival  in  the  workstation  market,  the 
company  decided  that  it  needed  a  set  of  CASE  tools.  Originally  the 
focus  was  internal  use,  but  this  focus  became  external  as  HP  saw  a 
business  <^){xirtunity. 

•  The  product  is  technical  CASE — ^not  MIS  CASE,  which  focusses  on 
commercial  applications. 

•  SESD  is  unusual  in  that  it  is  distributed  geographically  at  three  sites — 
Palo  Alto,  California;  Fort  Collins,  Colorado;  and  Pinewood  Bracknell. 
The  mxmal  model  is  for  a  divisicHi  to  have  one  t»se,  but  lo  provide 
local  suppcnt. 
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•  One  reason  for  this  geographical  distribution  is  the  expertise  in  Fort 
Collins,  where  OSF  Motif  was  developed.  Fort  Collins  contains  part  of 
the  Apollo  c^)earatifm«  wMch  will  eventually  be  integrated  into  Hewlett- 
Packaid. 


•  This  organisation  also  reflects  the  geographical  distribution  of  sales, 
which  is  20%  U.S.,  40%  Bin^,  and  40%  Japan. 

•  In  addition  there  is  a  great  deal  of  activity  in  Europe  with  the  EEC  on 
standards,  which  have  to  be  taclded  in  Europe. 

•  Each  country  has  to  integrate  third-party  products,  and  the  product 
changed  from  HPTEAMWORK  to  CADRE,  for  compatibiUty  with  all 
tool  vendors. 


•  A  great  deal  of  Andy  Wilde's  activities  at  the  moment  are  devoted  to 
marketing  and  to  supporting  the  integration  of  third-party  products  in 
Italy  and  Ranee. 

•  The  marketing  methods  that  HP  is  adopting  are  to  set  up  seminars  and 
to  liwife  tilie  soltwaie  devekqm^nt  managers. 


E 


Responsibilities  of  the 
Product  Manager/ 
Chief  Engineer 


After  the  presentation  on  Rank  Xerox's  intemal  organisation,  there  was 
a  di»ms^osi  on  die  sUnilarities  between  Rank  Xerox  and  Hewlett- 
Pactod,  CHit  of  which  a  number  of  important  points  arose. 

Andy  Wilde  felt  that  the  concept  of  total  worldwide  responsibility  of 
Ae  iHod^  mamget  was  a  critical  ingredient    success  in  the  develop 
ment  of  software  products,  and  the  key  to  the  sucoess  of  the  OAD 
(Office  Automation  Division). 

Digital  used  to  separate  functions  so  diat,  although  software  was 
developed  in  the  United  Kingdom,  responsibility  resided  in  the  United 
States.  This  division  caused  major  communications  problems,  and 
mcHrate  pxvldms  becau^  product  m^mageais  were  not  involved  in 
impcxtmt  decisions,  and  many  middle  managers  at  Reading  left  the 
company  (including  Andy  Wilde).  It  is  believed  that  Digital  has  had  to 
change  the  organisation  since  then  to  give  more  responsibility  to  the 
softw^  developo:^  in  Reading. 

Hewlett-Packard  had  been  able  to  give  the  OAD  full  autonomy,  even 
though  it  was  a  start-up  business,  because  several  key  people  w«e 
either  Britishers  who  had  worked  in  die  United  States,  or  Amoicans 
who  worked  in  the  Unit^  Kingdom. 
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•  The  disadvantage  of  giving  such  autonomy  to  each  division  was  the 
possibility  of  conflicts  and  interdivisional  rivakies  where  businesses 
overl^yped.  Although  in  the  past  Hewlitt-Packaid  had  a  Mssez-fEiiie 
asadmdit  to  these  probtos,  it  was  felt  hy  senkr  maimgmient  that  the 
merging  of  technologies  made  these  problems  more  and  more  probable, 
and  more  higher-level  decisions  were  now  taken  in  order  to  resolve 
these  issues  as  eaily  as  possible. 

•  The  geographical  distribution  of  product  responsibility  at  Hewlett- 
Padcard  recognises  a  trend  in  the  decreasing  proportion  of  HP's  United 
States  business.  Five  years  ago,  ibe  United  States  accounted  for  60%  of 
HP's  total  bu^ness;  now  that  percentage  has  reduced  to  40%. 

•  Hewl^-Packard  is  noi  very  good  at  separating  technical  and  line 
responsibility.  It  is  not  possible  to  progress  within  Hewlett-Packard 
without  becoming  a  line  manager.  HP  is  unwilling  to  pay  large  salaries 
to  technical  staff  because  the  company  can  take  a  graduate  and  make 
hinoAier  as  effective  within  three  years. 

•  In  order  to  clarify  the  definition  of  responsibilities,  the  Hewlett-Packard 
atiraticHi  vm  summarised  as  follows: 

-  The  product  manager  has  total  responsibility  for  the  production  and 
marketing  of  the  product  worldwide,  and  the  headcount  and  revenue 
generated. 

-  The  Hewlett-Packard  project  centre  in  each  country  is  responsible  for 
adapting  the  product  to  that  country's  and  clients'  needs. 

-  The  regional  managers  are  responsible  to  the  United  States  for  sales 
in  their  individual  markets. 

F  ,  

The  Next  Steps  •  in  addition  to  the  topics  that  have  already  been  defined  and  agreed 

upon,  Andy  Wilde  has  suggested  two  additional  ones: 

-  Product  life  cycles  as  a  topic  of  interest  The  life  cycle  repiesoi^ 
Hewlett-Packard's  best  practises. 

-  A  c^tinuatiw  M  the  discmssi^  m  responsibilities,  since  undoistand- 
ing  of  responidbilities  was  very  necessary. 

•  Rank  Xerox  would  continue  to  have  first  meetings  as  arranged  with 
Prime,  Digital,  and  Andersen  Consulting — but  a  further  contact  with 
Hewlett-Packard  would  be  arranged,  hopefully  before  the  end  of  May. 
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•  Hewlett-Packard  agreed  to  go  ahead  with  the  organisational  bench- 
mark; HP  agrees  that  the  list  of  topics  is  a  starting  point. 

•  FcMT  the  parties  to  the  bench-maik  to  meet,  it  will  be  necessary  to  define 
a  formula  and  a  format. 
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Structure  of  Meeting 

Prime  tqwesentative:  Andy  Ridgers 

An  introduction  by  Mike  Henry  on  the  concept  of  organisational  bench- 
marking 

A  presentation  by  Andy  Ridgers  on  Prime's  history  and  organisation 

Answers  from  Andy  Ridgers  to  the  points  in  the  provisional  list  of  topics 

A  final  discussion  on  the  next  steps,  and  Andy  Ridgers'  major  areas  of 
interest 

A  

Prm»  Organisatioil       •  Prime  is  a  U.S.  company,  owned  by  Americans,  although  more  than 

half  of  sales  are  outside  the  United  States.  Prime  has  a  new  organisation 
as  a  result  of  ^  J.H.Whitiiey  bi^ul^  which  has  resultal  in  br^ddng 
the  company  into  divisions,  aiMi  a  new  CEO,  Jack  Shields,  who  was 
brought  in  from  Digital. 

•  The  new  (XTganisatiCHi  at  Prime  is  split  into  5  parts:  international, 
systems  mtegration,  customer  service,  Computervision,  and  cornputer 
systems. 

•  Intemalidaal  consists  of  subsidiary  sales  and  service  organisations; 
there  is  no  international  marketing.  Marketing  sits  with  the  U.S.  sales 
organisation  and  covers  everything — ^product  definition,  product  plan- 
ning, annmincements,  trade  shows  and  pitnxM3tiotts  in  die  U.S.  Hiis 
width  of  the  marketing  function  causes  confusion.  The  international 
vice-president  is  an  American  based  in  Boston  and  Munich. 
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•  Systems  integration  is  the  glue  that  sticks  the  various  bits  together, 
such  as  EDI.  This  division  of  the  company  is  a  brand  new  develop- 
ment 

•  Customer  service  i$  tjhe  profitable  hardware  and  software  maintenance 
parts  of  the  com^pmy. 

•  Computervision  was  bought  by  Prime  because  Computervision  was 
number  two  in  the  CAD/CAM  software  market,  because 
Computervision  was  cheap  (it  had  made  announcemrats  fm  new 
products  that  were  delivoxd  12  months  late,  resulting  in  no  sales  for  12 
months),  and  because  as  a  software-only  company,  Computervision 
made  products  that  ran  on  Prime  equipment  and  thus  the  companies 
had  a  ccHnnxm  custtHner  base. 

•  Computer  systems  is  what  Prime  used  to  be  before  the  reorganisation, 
and  is  the  division  to  which  the  development  centre  at  Milton  Keynes 
reports.  Oxnimtra*  system  is  pat  of  the  U.S.  organisation,  not  part  of 
the  European  operating  companies.  Prime  U.K.  is  aware  of  them  since 
the  budget  comes  via  Prime  U.K.,  but  they  are  an  untappable  resource. 

•  Andy  Ridgers  has  been  head  of  the  software  development  centre  at 
Milton  Keynes  for  1  month.  He  took  the  job  on  the  condition  that  his 
boss  in  the  United  States  should  either  grant  the  centre  complete 
independence  or  make  the  centre  more  closely  integrated.  As  a  result  of 
a  decision  to  attempt  to  more  closely  integrate  the  centre,  Andy  wotks 
one  week  in  four  doing  exactly  the  same  job  in  the  United  States. 

•  Prime  started  in  the  U.K.  in  1972,  and  the  software  development  has 
been  going  since  1975.  Software  engineering  exists  more  as  a  result  of 
a  historical  accident  rather  than  as  a  deliberate  strategy.  However,  the 
U.K.  costs  are  now  $80-85K  per  head,  as  opposed  to  the  U.S.  costs  of 
$ 100-  105K  per  l^ad,  giving  a  higher  ROI  in     U.K.  In  addition,  the 
U.K.  now  has  some  critical  expertise  and  some  very  important  products 
are  done  here. 

•  All  software  and  hardware  development  is  U.S.  managed.  Although 
Prime  produces  worldwide  products  at  Milton  Keynes,  the  operation  is 
funded  from  the  U.S.  and  delivered  back  to  the  U.S.  Alpha  testing  is 
done  in  the  U.K.,  but  beta  testing  is  done  in  the  U.S. 

•  Milton  Keynes  has  about  70  people,  which  represents  30%  of  the  U.K. 
software  development  resource.  There  are  two  othor  sites  that  develop 
CAD/CAM  software  for  Computervision,  one  at  Harston  with  110 
people,  and  one  at  Penn  Street  with  38  people. 
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•  Although  reporting  directly  to  the  U.S.,  Milton  Keynes  has  all  the 
necessary  expertise  for  development,  testing  and  documentation — and 
has  respcMisibility  for  a  number  of  software  products,  such  as  OSI 

products.  Milton  Keynes  used  to  share  development  with  Australia  on  a 
database  product  that  was  marketed  in  the  U.S.,  but  Australia  has  since 
closed  and  all  the  development  on  this  key  product  is  done  in  the  U.K. 

•  Prime  has  a  number  of  problems  as  a  result  of  its  organisation,  and  as  a 
result  of  its  new  situation.  For  example,  the  U.S.  sales  organisation  uses 
engineering  to  h^  sdQ  to  ccitk^  dients,  but  tl»  uitexsiakHial 
organisation  has       {ffkiciti^  h^tXK  deciding  wi^ther  to  have  a 
European  development  capability. 

•  Although  son»  bridge  MQding  with  country  sales  cnrganisaticms  in 

Europe  has  taken  place  recently,  local  sales  offices  tend  not  to  ask  for 
support  since  they  are  organisationally  very  far  from  the  software 
development  in  Milton  Keynes  (i.e.,  the  two  organisations  meet  at  CEO 
level). 

B  

AnsA^rs  fircffii.^]ydy  The 
Ridgers  to  flie  Points 
in  the  Provisional  Q. 
List  of  Topics 

A. 
Q. 

A. 

Q. 
A. 

Q. 


A. 


benefits  of  a  Europ^n  Software  Development  Centre 

What  is  the  perceived  added  value  of  a  European  Software  Develop- 
ment Centre  from  the  point  of  view  of  the  client  /  parent  company 
management  /  local  management  dq)artmaits  /  distributors? 

Answered  in  previous  section. 

What  tri^ered  the  setting  up  of  the  Eur(^)ean  Software  Devel(^ 
ment  Centre  and  why? 

Answered  in  previous  section. 

Why  was  its  specitic  location  chosen? 

Reason  lo^  in  histiry,  altfaimgh  mMiakcr  building  was  sorted  sad 
occupied  in  Milton  Keynes.  After  2  years  it  was  still  half  enq>ty  and 
eventually  abandoned. 

Have  the  actual  benefits  turned  out  to  be  very  different  from  the 
original  braiefits  envisaged? 

Tbexe  were  no  spedfic  benefits  envisaged. 
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The  intern^  oipmisation  of  a  European  Software  Development 
Centre 

Q.  Does  the  European  Software  Development  Centre  have  a  mission 
staten^nt  and,  if  so,  what  is  it? 

A.  No,  (Hily  clear  owno^hip  of  a  set  of  products. 

Q.  What  are  the  goals? 

A.  Goals  are  associated  with  suat^^sful  maintenance  and  develi^Di^t 
in  terms  of  quality  and  delivery;  goals  are  not  tied  to  sales  or  any 
revenue  goals.  Customer  satisfaction  via  feedback  on  bugs  and 
usability  is  also  us«i  as  a  quality  measure.  Prime  has  rec«itly  gcmc 
through  a  significant  change,  and  although  2  years  ago  goals  mi^t 
have  been  growth  oriented,  now  they  are  cost  and  profitability 
oriented. 

Q.   How  is  the  organisation  structured  in  terms  of  functions, 

worlcgroups,  roles  and  responsibilities,  and  reporting  relationships? 

A.   Software  ^velopmmt  at  Miltcm  Keynes  is  grouped  into  teams,  and 
the  larger  groups  have  section  managers.  There  is  also  a  team  of 
authors  who  are  not  integrated  into  the  development  teams,  but  this 
setup  is  believed  to  be  wrong  and  liable  to  change. 

Milton  Keynes  also  has  an  accountant  and  human  resources  man- 
ager and  a  small  operations  soc^m,  Tim  aosouni^t  is  not  a  manage- 
tmat  accountant — mort  of  a  booldceeper. 

Testing  is  part  of  engineering;  engineers  do  everything,  from  testing 
to  documentiOicHi.  Howcvct,  1  product  has  35  engii^ers,  and  so 
there  are  scmie  test  specialists  (m  this  product. 

Q.   What  are  its  dimensions  in  terms  of  number  of  staff,  products  and 
locations? 

A.   There  are  three  managers — one  with  4  teams,  two  with  3  teams 
each,  and  about  4-5  engineers  per  temn.  Tbe  n^attcmsMp  erf  teasm  to 
pro(^Kts  is  quite  varied,  so  they  have  one  team  of  6  that  looks  after 
56  products,  mi  a  team  of  35  m  one  product 

Engineers  produce  a  gl<rf)alised  product,  with  all  messages  in  a 

separate  area  for  later  localisation  by  the  international  group,  which 
also  changes  the  documentation.  They  also  have  intemationalisation, 
so  that,  for  example,  a  4GL  will  cope  with  the  different  ways  of 
fcHcmatting  numbers  by  access  to  a  library  of  routines. 
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Q.  What  is  the  skills  matrix  of  die  organisation? 

A.  En^beers,  Auth(»^  Operates^,  Accountants,  Human  Resooices, 
Managmient 

Skills  are  related  to  products — e.g.,  X400.  They  have  a  goal  of  not 
reoniting  people  witiiout  a  degree. 

Q.   What  lessons  have  been  learned  during  the  setting  up  and  running  of 
the  Eun^)ean  oiganisation? 

A.   The  lessons  were  learned  a  long  time  ago,  but  they  are  contiaually 
releaming  how  to  interface  with  the  United  States. 

They  suffer  from  the  not-invented-here  syndrome,  and  the  lack  of 
informal  communications  that  arise  from  not  having  conversations 
while  passing  each  other  in  the  corridor  or  in  meetings.  As  a  result, 
the  new  initiative  of  wcxrking  ckmt  is  being  tried. 

There  are  about  100  trips  per  year,  some  people  travelling  2-3  times, 
some  nKwe.  However,  since  the  U.K.  now  has  total  de^ft^ioj^mem 
responsibility  for  the  single  most  important  software  product,  the 
U.K.  now  tends  to  get  more  visits  from  the  United  States.  Andy's 
boss  visits  once  a  quarter,  as  does  his  boss's  boss.  Peers  tend  not  to 
visit. 

Q.   What  software  performance  metrics  are  used — e.g.,  for  evaluating 
ttie  effectiveness  of  software  development  process  and  the  quality  of 
cm^ut?  (e.g.,  number  of  lines  of  code  p^  module;  numb»  of  &ults 
po"  line  of  code) 

A.  Metrics  =  problem  reports.  Piime  has  no  pedommn^  m^ics  fcH' 
lines  of  code,  code  goals,  or  size  gc^.  Prime  has  a  niunber  of 
bench-marks  for  product  perfonnance. 

Prime  p(9r&»ms  post-mortem  reviews  to  identify  false  si^,  and  to 

review  how  far  marketing  moved  the  goal-posts.  Prime  also  has 
varying  degrees  of  inspection,  and  has  instituted  the  Fagin  method — 
With  readers  and  moderators  etcetera — but  not  as  a  standard. 

Prime  doesn't  use  scientific  estimating  or  history  for  estimating;  a 
senior  consultant  produces  a  gross  person-years  estimate. 

Q.  Recruiting  ^pectations  with  resp^t  to: 

-  Recruiting  experts 

-  Remiiting  to  train 
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A.   Prime  recruits  experts  unwillingly,  but  where  necessary.  Prime 
recruits  to  train,  to  grow  internally  for  all  the  standard  reasons. 

The  last  expert  Prime  recruited  was  2  years  ago,  when  the  company 
needed  somebody  who  had  commercial  database  experience — that 
is,  not  a  technical  expert,  but  someone  with  an  understanding  of  the 
clirat's  needs. 

Budget  and  headcount  are  known,  but  are  not  performance  mea- 
stnes.  A  year  ago,  headccKuit  smA  exp&a&tare  wete  in^calan^  now 
CHily  expoiditiue  is  important 

Andy  Ridgers  has  been  with  Prime  for  eight  and  a  half  years.  Al- 
though IC^  fe  Ae  industry  avmge  of  attrition.  Prime  has  been 

consistently  below  8%.  However,  last  year  was  bad  because  of  the 
uncertainty  about  the  company's  future,  and  in  November,  30 
people  were  laid  off. 

Q.   How  long  did  it  take  to  set  up  the  European  Software  Development 
Centre,  and  what  is  the  process  and  culture  for  managing  change 
requirements? 

Everything  has  changed  because  the  culture  allows  European 
organisations  to  do  it  their  way  within  certain  constraints.  They  can 
woric  dififemitly  in  Eitf^,  and  have  some  autoncmiy.  Prime  does 
not  have  a  salary  freeze,  for  example.  It  is  generally  recognised  in 
the  United  States  that  attempts  to  control  too  tightiy  can  stifle 
research  and  development. 

There  is  no  real  lobbying  mechanism  for  deciding  where  a  product 
will  be  developed,  although  the  initial  owner  of  the  idea  has  a  strong 
case.  ThCTe  can  be  conflicts,  especially  for  such  things  as  EDL 
Pdme  tries  to  do  it  by  mutual  agreement,  but  if  necessary,  the  VJ*. 
will  bang  heads.  If  the  product  is  very  large,  a  formal  study  may  go 
for  consideration  by  the  engineering  and  marketing  V.P.s.  A  major 
om^S^^m  is  the  resources  that  are  available,  or  that  could  be 
fieed. 

Prime  has  formal  reviews  but  they  are  not  decision-making  pro- 
cess*^ and  the  process  is  never  followed  to  the  let^.  ftinae  is  not 
totally  committed  to  quality  reviews,  and  (k>es  not  use  external 
teams. 

The  interactions  of  a  Europ^n  Software  Development  Cratre  with 
other  organisations 

Q.  What  are  the  role  and  responsibilities  of  the  European  Software 
Develc^n»nt  Centre  with  respect  to  the  parent  oiganisation? 
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A.  Answered  in  pre\dous  section. 

Q.  W]ltotai«tiMiiUia1lu^totbepm«ntor^inba^^ 

Gessc&  exist  ftx  intercommunication,  reporting,  inifc»mation  Sharing, 
etcetera. 

A.  Electronic  mail,  first  commercial  in^lementati<Mi  of  X25, 

company  wide  documentation  structure,  weekly  status  reporting  on 
all  projects  showing  exceptions  to  plan,  a  weekly  consolidated  status 
report,  and  a  weekly  phone  call  if  there  is  geographical  separation  of 
programme  management  from  the  develq^iment  team  and  a  WMifa*- 
emx  call  if  aitical. 

Q.  How  are  funding  and  budgeting  managed? 

A.  Funding  is  a  percentage  of  corporate  revenue,  and  there  is  an  annual 
budget,  headcount,  and  list  of  things  to  do.  There  are  meetings  once 
<x  twice  a  year  in  order  to  decide  sales  and  mioiceting  prioities. 

There  is  no  real  concem  about  headcount,  but  more  about  expendi- 
ture. HffiTcfore,  provided  fliey  are  profitable,  additional  people  can 
ht  taken  on. 

Q.  How  is  the  performance  of  the  European  Software  Development 
Ontre  measured? 

A.  They  are  judged  on  results,  as  above. 

Q.  Wfa^coixKiionaUtyof  daigndevd^m^tandiH]^>oftpRX^^ 
and  development  tools/environments,  cxisis  betw^i  die  Eurc^ean 
and  parent  organisations? 

A.  Si^ort  processes  and  0baKi  reviews  are  coaaaiiQii,  ^  all  de^^^&p- 
ment  tools  and  environments  are  different  everywhere,  and  up  to  the 
individual  manager.  Attempts  to  enforce  commonality  have  failed  in 
the  past. 

Q.  To  what  extent  is  there  inteichange  of  staff  between  the  European 
and  parent  organisation? 

A.   There  is  not  much  interchange  of  staff,  perhaps  for  stints  up  to  one 
month,  although  there  have  been  rare  secondments  of  up  to  one  year. 

There  are  no  major  areas  of  difference  off  advantage  between  the 
United  States  and  the  United  Kingdom,  except  that  there  is  no 
acceptance  in  the  U.K.  of  incentivisation  and  bonus  payments  for  on- 
time  c(niipletion. 
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Q.  How  does  the  European  Software  Development  Centre  relate  to: 

-  Endusors 

-  Marketing 

-  Sales 

A.  Decisums  on  |»oducts  are  tm^  as  a  result  of  a  two-way  discussirai 
between  research  &  development  and  marketing,  although  market- 
ing has  the  last  word  on  whether  to  drop  extra  requirements,  wait, 
etcetexa.  D6di^[»is  are  a  ccmlinnous  process. 

A  programme  manager  will  produce  a  requirements  document  that 
is  purely  technical,  but  a  functional  specification  wiU  be  written  by 
an  engineer.  This  specificaticm  will  contain  service  plans,  a  dei^gn 

specification,  a  training  plan,  documentation  specification,  etcetoa. 
Approval  of  the  functional  specification  is  conducted  by  many 
people — such  as  marketing,  customer  service,  and  even  occasionally 
sates. 


The  functional  specification  is  very  detailed  and  unique,  but  has 
some  piofaleDds  ^sux  it  does  not  specify  what  the  product  does  not 
do,  and  requires  interpretation  by  a  senior  consultant.  The  documait 
is  also  very  technical  and  can  be  difficult  for  marketing  to  read. 
Such  a  document  can  take  a  long  time  to  produce,  and  sometimes  a 
great  deal  of  software  is  already  mitten  by  the  time  the  docun^nt  is 
approved. 

What  are  the  roles  and  responsibilities  of  the  European  Software 
Developm^t  Centre  relative  to: 

-  Pre- sales  support 

-  Post-prodiKt  hunch 

-  Product  devel(^ment /launch 

Prime  does  shghtiy  more  support  than  before,  although  no  pre-sales 
^ippoft  m  product  launch.  TTie  official  route  for  an  En^h  end  xmr 
with  a  post-sale  problem  would  be  via  Hayes  in  the  U.K.,  tiien  to 
U.S.  customer  service,  and  finally  to  Milton  Keynes, 


A  Final  Discussion 
on  the  Next  Steps, 
and  Andy  Ridgers' 
Major  Areas  of 
Mteiest 


•  Andy  will  be  pr^>ared  to  go  forward  to  the  next  stage  on  a  'suck  it  and 
see'  basis. 

*  MajcK*  areas  of  interest  are: 

-  Relationships  with  other  parts  of  the  organisation 

-  Commumcations  and  teamwork  with  the  U.S.  parent 
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Appendix:  Digital  Equipment 


Structure  of  Meeting 
IM^Mr^Hissentative:  JacSimensen 

An  introduction  by  Mike  Henry  on  the  concept  of  organisational  bench- 
marking 

A  discussion  on  the  next  steps,  and  reactions  from  Digital 

An  ^lanation  of  Digital's  organisation  and  Jac  Simensen's  re^xmsibiU- 
ties 

A  description  of  the  Rank  Xerox  organisation 

A  final  di^s»on  on  the  next  steps 

A   

Reactions  from  •  The  initial  reaction  is  that  it  is  an  intriguing  idea  wcnlfa  exploring. 

Digital 

•  Jac  referred  to  balancing  the  3  Cs — collaborators,  customers,  and 
cfHX^titors. 

•  Jac  can  perceive  the  addition  of  other  companies  down  the  road,  but 
initially  the  reaction  to  the  companies  involved  is  as  follows: 

-  Xerox  is  O.K.,  although  a  bit  of  a  a>nq)etitt)T. 

-  Andersen  is  no  problem  at  all. 

-  Prime  is  also  a  customer,  so  no  problem. 


YEXf^ 


33 


EUROPEAN  ayrWAtg  DEVELOPMENT  CENTRES-ORGANISATION  BENCH4yiWiK  INPUT 


-  Hewlett-Packard  presents  some  concern,  since  it  is  perceived  as 
having  the  potential  to  join  Digital  and  IBM  in  the  top  tier.  Notwith- 
standing tfiis  wOTry,  HP  doesn't  present  a  critical  go/ao-go  concern. 

-  IBM  on  the  other  hand  would  definitely  mean  a  no-go  d«;ision; 
Digital  is  not  prepared  to  share  anything  with  IBM. 


-  Bell  Northern  is  O.K. 


-  Sionens  is  probably  O.K.;  it  cooperates  on  telephony,  but  could  be  a 
major  competitor  in  the  future. 

•  Some  interest  was  expressed  in  the  phase  review  process.  Digital  has  a 
veay  specific  process  diat  is  both  horrible  and  wonderful  at  the  same 
time. 


Jac  would  be  very  happy  to  participate  in  a  pilot  in  order  to  see  if  it  can 
woik,  IH^tal  in  ibc  U.K.  no        has  such  a  parentAMld  rektitmshq) 
with  the  United  States  as  before,  but  they  have  made  nutny  mistakes 
and  would  benefit  from  a  learning  process. 


B 


An  Explanation  of 
Digital's  Organisation 
and  Jac  Simensen's 
Responsibilities 


•  Jac  Simens(ai  is  directly  responsible  for  an  organisation  that  includes 
Scotland,  E&e,  and  Australia  as  well  as  Reading.  However,  he  is  the 
senkr  m^mmag  manager  in  Reading,  and  has  lespcHisibUiQr  &x  all 
fadUties,  with(Htt  having  line  r^ponsiUSity  for  all  die  people. 

•  Software  development  started  in  the  U.K.  18  years  ago  but  with  a  U.S. 
focus,  mostly  working  on  X.25.  They  learned  about  Eurcqiean  markets, 

and  their  leadership  in  OSI  came  out  of  Europe,  as  did  open  systems, 
although  they  are  no  longer  such  leaders  in  open  systems  as  before. 

•  Digital  was  originally  forced  to  have  a  European  organisation  in  order 
to  deal  with  the  EEC,  but  now  such  an  organisation  is  part  of  Digital's 
business  practise.  Digital  is  becoming  more  and  more  international,  and 
Hxam  is  mw  moit  revraue  and  profit  outside  the  United  States  dian 
inside. 


•  Jac  Simensen  was  originally  recruited  as  an  Ethernet  expert,  and  ended 
up  hmimg  m  SSO-perscai  organisation  that  was  eventually  split.  Now, 

apart  from  his  responsibilities  to  support  sales  (etc.)  as  senior  enginCCT- 
ing  manager,  he  is  responsible  for  corporate  backbone  networks. 

•  Digital  has  1,500  engim^ing  and  support  staff  in  Europe.  In^  UX 
there  are  800  in  software,  approximately  one-third  of  whom  report  to 
Jac,  as  well  as  60  hardware  people  who  aU  report  direcdy  to  Jac. 
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•  There  are  120-150  software  people  in  Italy,  and  40  hardware  people  in 
Gennany  (in  Munich)  working  on  disks  and  storage. 

•  There  are  250  software  people  in  France.  Digital  has  been  unsuccessful 
with  hardware  in  France,  but  now  has  a  worldwide  telecommunications 
centre  in  France  in  Valbonne.  Digital  was  given  very  preferential  terms 
by  Ae  Bk^k^  goiyammait,  which  wants  to  dev^iop  a  lead  in  ccHnmuni- 
cations  aiul  has  develcqied  a  very  good  relationship  as  a  result 

•  nierc  are  40-80  people  in  Scotland. 

•  The  European  headquarters  is  in  Geneva. 

•  Many  U.K.  product  have  been  successful.  France  was  very  slow  tt>  get 

off  the  mark.  Italy  has  applied  the  lessons  learned  very  well  and  is 
doing  better  earlio:  than  the  others.  Digital  also  has  a  silicon  plant  in 
Israel. 

•  The  United  Kingdom  is  the  home  of  a  number  of  important  Digital 
products  such  as  All-in-One,  Corporate  backbone  networks,  VMS(TP), 
and  MaSL  Italy,  oa  ^  oth^  haad,  is  dedicated  to  VMS,  which  is  run 
fixmi  the  U.S.,  so  that  code  frcnn  Italy  is  integral  into  the  United 
States. 

•  Digital  has  a  typically  loose  organisation.  Although  it  looks  as  if  Digital 
has  a  European  organisation  reporting  to  David  Stone,  the  International 
V.P.  in  Geneva,  the  organisation  really  reports  to  Bill  Johnson  in  the 
U.S. 

•  Corporate  backbone  networks  and  mail  in  the  U.K.,  and  communica- 
tions in  France,  report  to  Bill  Johnson  in  the  U.S.,  who  is  responsible 
for  all  tdeeim^ffiiitixcaiicHis  sad  n&iwodss  pfodi^ts.        products,  such 
as  AU-in-Qne  and  VMS,  rqxjrt  to  the  VJ*.  in  chsatgp  of  DSSG. 

•  All  funding  strategies  go  through  the  United  States,  but  all  strategies 
have  to  be  run  round  die  a&xev  groups  before  tbe  strategies  are  fonnally 
{absented. 

•  Digital  is  in  the  process  of  a  massive  reorganisation  at  most  levels, 
partly  because  tk  the  de^iartiBe  of  Jack  Shields  tof^rtee.  Jack  Shidds 
used  to  head  up  sales,  service  and  support,  and  industry  marketing, 
while  Jack  Smith  was  responsible  for  engineering,  manufacturing,  and 
I»oduct  marketing.  Jick  Shields'  parte  of  the  organisation  (except 
industry  marketing,  whix^  k  dis^JpiSfaing)  are  being  moved  undicr  Jack 
Smith,  who  is  becoming  a  more  classic  COO.  Both  the  Jacks  were 
directiy  under  Ken  Olsen.  The  reorganisation  should  be  complete  by 
July. 
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•  Bill  Johnson's  Telecommunications  and  Networks  is  divided  into  five 
parts — CBN  (Jac  Simensen),  Telecommunications,  LAN,  LAA,  and 
OSS.  There  is  a  great  deal  oi  cross^xxtmuinioaticni  as  well  as  upwards 
and  downwards  communic^oii  in  a  kind  of  matrix  structure.  For 
example,  each  of  the  five  groups  has  a  strategist,  and  Bill  Johnson  has  a 
strategist,  and  they  all  communicate.  One  of  Digital's  major  strengths 
is  diat  an  pcodui^  integrate. 

•  Strategies  get  beaten  up,  but  people  have  a  significant  amount  of 
autonomy.  Strategy  reviews  are  advisory,  and  take  place  at  the  highest 
level  by  DEC's  "best  ami  finest"  liigh-level  technical  V.P.S,  but  they 
also  have  teeth. 

•  Maiiceting  and  engineering  report  separately,  butuit»act  apeat<feaL 
There  is,  however,  a  major  change  taking  ^U(^  as  ^gioeeiing  is 
evolving  into  more  of  a  business  unit.  Engineering  managers  were 
measured  perceptually,  but  now  they  are  going  to  become  more  like 
busine^  managers  who  have  revenue  and  profit  objectives. 

•  There  is  also  a  cultural  change  as  Digital  looks  at  investment  opportu- 
nities, and  a  great  deal  of  activity  is  taking  place  in  the  Far  East.  Thwe 
is  also  a  strong  European  feeling,  and  it  is  believed  that  Geoff  Shing^^ 
in  the  U.K.  and  P.C.  Fallohi  in  France  are  becoming  more  inqpor^t  in 
the  company. 

•  The  greater  importance  of  Europe  is  due  principally  to  success.  It  has 
taken  15  years,  and  an  accelerated  pace  in  the  last  five  years,  for 
Digital  to  prove  itself  and  get  control  of  its  own  activities. 

•  Like  other  equipment  vendors,  Digital  must  change  towards  more 
services  orientation  and  look  for  where  it  can  add  value,  and  where  the 
client  wlQ  i»y  to  extra  s^vi^. 
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Appendix:  Andersen  Consulting 


Structure  of  Meeting 

Andersen  Software  representatives:  Aiufaew  May  and  David  Sallis 

An  introduction  by  Mike  Heniy  on  the  concept  of  organisational  bench- 
marking 

Personal  introductions 

An  initial  discussion  on  the  background  and  benefits  of  a  European 
Software  Development  Centre 

A  review  with  Andersen  Consulting  of  the  points  in  the  provisional  Ust  of 
topics 

A   

Personal  David  SalUs  was  a  consulting  manager  with  Andersen,  mostiy  in  the  oil 

Mttoductions  industry.  He  mana^  60  people  wcn4dng  on  a  major  systems  ctevelop- 

ment  job  with  Shell  in  Malaysia,  before  going  to  Chicago  for  18  months. 
His  function  in  Chicago  was  to  be  a  liaison  with  the  various  European 
software  development  projects.  Since  last  year  he  has  been  responsible 
for  tite  new  Eun:^>ean  Softw^  Development  Centre  in  SopMa-Antipolis 
in  die  south  erf  France. 

Aocbew  May  has  been  in  software  product  marketing  for  some  considCT- 
aUe  time — with  Metier  and  then  with  Arthur  Young.  Andrew  is  now 
responsible  for  marketing  Foundation,  which  is  the  Andersen  set  of 
CASE  tools. 


YEX»E 


37 


EUROPEAN  SOFTWARE  DEVELOPMENT  CENTRES-<»K3ANfSATION  BENCH-MARK  INPUT 


B  

An  Initial  Discussion 
on  the  Background 
and  Benefits  of  a 
European  Software 
Develc^jmeiit  Centre 


The  history  of  Andersen  Software  in  Europe  is  that  each  country  devel- 
oped its  own  software  for  its  own  market,  so  Andersen  had  development 
teams  in  Spain  and  Italy,  as  well  as  the  U.K,  By  mid-1988,  Andersen 
also  had  a  substantial  software  laboratory  in  Chicago,  and  at  this  stage 
the  company  decided  to  centralise  European  efforts  in  one  place  and 
selected  Sophia- Antipolis,  near  Nice  in  the  south  of  France. 

In  January  1989,  the  lab  was  established  but  had  significant  teething 
problems  over  staffing,  telecomms,  equipment,  finance,  and  communica- 
ticHis  wMi  CMcago.  By  mid-19t9,  the  first  project  was  moving  smoothly, 
though  still  with  communication  problems  with  Chicago  (langu^e, 
visibility,  credibility).  A  substantial  applications  software  project  was 
added,  and  permanent  premises  commissioned  nearby. 

By  the  end  of  1989  the  first  software  was  delivered  to  a  pilot  site  in  the 
United  States  and  was  very  well  received.  A  support  system  was  estab- 
lished, with  one  developer  going  to  the  pilot  site;  investment  in  radio- 
pagers  was  unnecessiffy  since  the  seomd-line  supp(»t  was  not  needed. 

The  move  to  the  new  premises  was  made  in  March  1990,  but  not  fully 
(XH^l^ed  oatil  May,  although  ^idersen  lost  only  2  days  of  production. 
The  sate  am  hm  spm»  for  75  people,  but  with  50  people  in  appliradons 
software  and  17  in  systems  software,  Andersen  still  does  not  have  room 
for  the  35  people  in  three  teams  in  Italy  (in  Milan,  Padua,  and  Parma). 

From  a  marketing  perspective,  the  three  main  benefits  of  the  European 
Software  Development  Centre  are  credibility  to  the  clients,  proximity  to 
the  market-place,  and  the  ability  to  appreciate  the  physical  differences 
between  the  regions. 

David  Sallis  beUeves  that  having  worked  in  Chicago  for  18  months  was  a 
key  advantage  to  die  manager  of  the  European  Centre  when  he  set  k  up. 

The  degree  of  investment  is  dependent  on  the  worth  of  the  business  case 
that  is  presented  to  the  investment  committee. 

A  great  deal  (more  than  50%)  of  the  software  development  staff  are 
cycled  through  from  the  consultancy  practise,  and  they  all  have  a  com- 
mon grounding  in  the  use  of  the  Andersen  CASE  tools  as  part  of  the 
tetsic  tndamig.  IMs  high  level  of  movenmt  widtin  the  (»rganisati<»i 
provides  an  advantage  in  that  all  the  20,000  field  staff  in  consultancy  are 
aware  of,  use,  and  can  potentially  sell  the  CASE  products. 

As  well  as  the  advaittafe  <tf  selling  the  products,  there  is  also  the  advan- 
tage that  user  requirements  arc  captured  better,  and  f^dback  after  prod- 
uct launch  is  also  improved. 
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The  nature  of  Andersen's  software  products  requires  a  very  fast  response 
and  a  fast  production  cycle  in  order  to  get  to  the  market  in  time. 

A  strength  of  the  organisation  is  the  large  amount  of  local  autonomy 
inherent  in  a  partnership  and  the  tendoicy  to  decentralise. 


A  Review  with 
Andersen  Consulting 
of  the  Points  in  the 
Provisional  List  of 
Tc^ics 


The  beneRts  of  a  European  Software  Devdopm^  Centre 

Q.  What  is  the  perceived  aided  value  of  a  European  Software  Devdqp- 
DMnt  CeatTt  from  the  p<Mnt  of  view  of  flie  client  /  parent  company 
manag^oient  /  local  management  departments  /  distributors? 

A.  Demonstrates  internationalism  and  wmldwiiki  a>mmitmait.  U 
provides  a  European  skill  base  for  custinxier  sales  and  support,  and 
local  market  support — e.g..  Bull. 

Opmtions  are  less  cosdy,  there  is  increased  staffing  flexibility  due 

to  decentralisation  and  they  are  located  in  a  high-technology  commu- 
nity and  have  a  platform  for  building  skills  in  Europe.  There  are  also 
financial  advantages  and  support  advantages  for  the  French  prac^se. 


Q.  What  triggered  the  setting  up  of  the  European  Software  Develop- 
ment Centre  and  why? 

A.  Impetus  was  the  growth  of  European  sales,  and  the  med  for  a  plat- 
form for  local  support. 

Q.  Why  was  the  spmfic  location  chosen? 

There  were  significant  financial  advantages,  tax  breaks,  internal 
funding  and  low  costs.  Also,  being  in  a  high-technology  ccwnmunity 
means  opportunities  for  joint  ventures  and  eventually  a  skilkd  local 
labour  tmikst,  and  it  is  an  atbractive  location  fca  staff. 

Q.  Bme  the  actual  benefits  tum»i  out  to  be  very  different  from  the 
odginal  benefits  ravisaged? 

A.   The  financial  benefits  have  been  realised;  it  is  too  early  to  tell  for  the 
rest. 


The  internal  organisation  of  a  European  Software  Development 
Centre 

Q.   Does  the  European  Software  Development  Centre  have  a  missi(Hi 
statement  and,  if  so,  what  is  it? 
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A.  The  mission  for  Foundation  (the  CASE  product)  is: 

To  build  a  CASE  product  that  is 

•  a  market  leader 

•  full  life-cycle 

•  integrated 

•  industtM  i^rraigth 

•  international 

•  multiplatfonn 

Q.  What  ate  the  g(^s? 

A.   •  Develop  a  substantial  development  centre  with  highly  skilled 
multidisciplinary  staff 

•  Detmrnstrate  international  presence 

•  Support  Eun^ean  markets 

•  Reduce  costs 

•  Provide  platf(Hm  for  skiUs  devek^ment 

Q.  How  is  the  organisation  structured  in  terms  of  functions, 

workgroups,  roles  and  responsibilities,  and  reporting  relationships? 

A.  Reports  administratively  to  Paris,  and  functionally  to  Chicago. 

Andorsen  is  now  nsgrating  to  a  piodiict^ori^ted  organisailcm  x^toe 

fffoduct  executives  will  control  development  of  software,  documen- 
^on,  training,  support,  marketing  and  sales  support.  Some  func- 
tiKHis  mcik  as  f^mc  support  and  (^^cting  the  training  will  be 
handled  regicHially. 

Andersen  has  a  major  career  problem  with  the  introduction  of 
sodmme  engjneCTS.  Traditionally,  witii  a  strong  corporate  culture, 
progression  was  towards  partner  or  out  of  the  firm.  This  dichotomy 
is  very  difficult  to  maintain  when  recruiting  technical  specialists  and 
this  problem  is  not  fully  resolved. 

Q.  What  are  its  dixtKmsions  in  t^ms  of  number  of  staff,  products  and 
locations? 

A.   55  in  Sofia 
25  in  Padua 
12  in  Milan 
20inIjond<Hi 
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They  have  product  responsibility  for  5  products — the  planning  tool 
for  workstations,  the  batch  implementation  tool,  the  IMS/DC  imple- 
ineiitatum  tool,  and  2  iilq)lmientation  tools  for  Bull,  GGOS  7  ai^ 
GC0S8. 

Q.   What  is  the  skills  matrix  of  the  organisation? 

A.   Almost  all  are  software  engineers  at  present.  These  are  recruited 
from  European  universities  or  borrowed  from  consulting  offices. 

With  the  new  organisation,  they  arc  attracting  a  wido:  mix — araii^rs, 
technical  writes,  etcetera. 

Q.  What  I^S(Mis  have  bera  teamed  dunng  the  setting  up  and  running  of 
the  European  (sganisation? 

A.  Plan  fosc  growth,  establish  critical  mass  early,  and  plan  for  twice  the 
office  space  you  think  you  need. 

Make  a  senior  person  from  central  available  during  set-up  in  order  to 
pull  strings,  get  resources,  and  ensure  visibility. 

Make  the  centre  as  autonomous  as  possible  andpofonn  as  many 
functions  as  possible  locally. 

Estidblish  good  communications  (WANs). 

Have  an  appropriate  level  oi  administrative  support  for  new  staff 
(housing,  cars,  hand-holding). 

Recognise  the  heterogeneity  of  Europe  as  compared  to  the  United 
States. 

Have  frequent  (4-8  weeks)  meetings  between  semor  staff  on  both 
sides. 

Q.  What  software  performance  metrics  iffe  used — e.g.,  for  evaluating 
the  effectiveness  of  the  software  development  process  and  the 
quality  of  output?,  (e.g.,  nimiber  of  lii^  of  code  per  module;  number 
of  f  atdts  pa-  line  of  code) 

A.   Don't  measure  performance  except  by  detailed  budgeting,  planning 
and  reporting  basal  on  standard  guidelines  (METHOD/1). 

Periodic  indq)eiKient  QA  reviews. 

After  beta  tesidng  they  nieasiae  px)duct  quali^  by  nundjo^  and 
seventy  of  wpomd  {salts. 
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Q.  Recruiting  expectations  with  respect  to: 

-  Recruiting  of  experts 

-  Recruiting  to  train 

A.   Recruit  internally  and  externally — with  good  results  so  far  and 
better  dian  in  the  Unit^  States. 

Q.  How  long  did  it  take  to  set  up  the  European  Software  Development 
Centre,  and  vibM  is  liie  fnoc)^  and  cit^me  for  managing  change 
lequirements? 

A.   From  site  selection  to  permanent  premises  took  two  years. 

The  miaractions  of  a  European  Softuraure  Devdopment  Cmb^  with 
other  orgaiiisati<ms 

Q.  What  afe  the  f(^asdif»^p<xmlxQities<^ 

Devdopment  Centre  wi&  ]reiq)ect  to  the  paroit  ^amsation? 

A.   Develop  products  for  the  Foundation  CASE  family. 

Provide  a  support  centre  ftjr: 

-  European  Clients 

-  European  Markets  (BULL) 

-  Eiin>pean-devel(^)ed  products  (intmm) 

Support  sales  and  marketing  in  Europe. 

Q.  Wlutt  axe  the  interfaces  to  the  parent  organisation,  and  what  pro- 
cesses exist  for  intm:Qmmunication,  reporting,  infonnation  sharing, 
etcetera? 

A.   Transition  to  the  new  organisation  is  proving  very  painful  because 
of  the  staffing/financial  rearrangements  implied.  The  new,  detailed 
implementation  of  the  organisation  is  not  yet  decided. 

WAN/E-mail 

Access  to  central  mainframe 

Wang 

Fax 

Regular  meetings 
Satellite  video 

Q.  How  is  funding  and  Inidgeting  managed? 

A.  Top-down  investment  number  ($  40  mUHon  for  product  develop- 
n^t  alone) 
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Bottom-up  proposals  from  executives 
Negotiation  until  tiiey  meet 

Funding  from  joint  ventures  with  vendors  and  consulting  branch 

Q.  How  is  the  performance  of  the  European  Software  Development 
Centre  measured? 

A.  Against  btdget,  schedule,  quality 

Q.  Wwt  «»iiaaonaIity  of  design  (kvelopment  and  support  processes, 
and  ^^Iqpment  tools/environments,  exists  betweoi  d»  European 
and  parent  organisations? 

They  use  all  their  own  CASE  tools,  alcmg  vnik  comnKm  otho*  tools, 
comnxm  architectures  and  environn^nts. 

Q.   To  what  extent  is  there  interchange  of  staff  between  the  European 
and  parent  wganisatifm? 

A.   Throughout  the  firm  there  is  significant  international  staff  move- 
OEient  The  par^t  ai^  iht     are  stafibd  largely  with  consulting 
people  from  the  ISO  offices  worldwule. 

Q.  How  does  the  European  Software  Development  Centre  relate  to: 

-  End  users 

A.  Limited  at  present  to  promotions,  pilot  sites,  trade  shows.  Will 
increase  to  encompass  support  and  training  when  products  are 
launched. 

-  Marketing 

Provide  input  for  mariceting  materials,  support  for  trade  stK}ws, 
PR,  demos,  presentaticms,  etc&tsrtL 

-  Sales 

Sales  fOTce  training,  sales  materials,  client  visits  and  prtmioticMis. 

Q.   What  are  the  roles  and  responsibilities  of  the  European  Software 
Development  Centre  relative  to: 

-  Pre-sales  support 

A.   Marketing  materials,  demos,  presentations,  promotions,  trade  shows, 
PR,  case  studies 

•  Post-product  laiuich 
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A.  Seccmd-line  siq^oat  and  installation 

-  Product  develoiMDQent  Munch 
A.  Launch  c<»nndttee,  press  plus  above 
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Appendix:  Siemens 


Structure  of  Meeting 

$i»E^is*  lepresentative:  Geoi^Broc4e 

An  introduction  by  Mike  Henry  on  the  coiK^t  of  oc^nisatitMial  bench- 
marking. 

A  gencfal  discussion  on  Sienoens'  expm^ces  in  the  U.K. 

A  

Sialic'  .  Siemens  is  implementing  Fagin's  appioach  to  design  reviews. 

Experi^ces 

•  Siemens'  software  development  staff  in  the  U.K.  has  grown  from  zero 
to  80  people  in  four  years. 

•  Siemens  in  Woodley  reports  to  Germany,  not  to  the  UJ8L  opiating 
company,  Siemens  pic. 


Woodley  is  developing  a  working  environment  that  is  different  from 
the  company  culture.  Siemens  has  an  enormous,  very  efficient  bureau- 
cracy that  is  100%  paper-based,  but  is  developing  a  software  village 
appioach. 

AH  staff  are  new  to  Siemens;  there  are  no  long-term  Siemens  employ- 
ees. 

No  managers  are  connected  to  the  electronic  mail  system;  only  software 
developers  use  it. 

Sieimns  is  moving  its  corpcsate  headquarters  back  to  Boiin. 

Because  of  the  Nixdorf  takeover,  Siemens  is  now  having  to  provide 
tedmical  and  service  support  in  a  much  bigger  way  and  has  gcMie  &mn 
TSSQ  to  1,000  people  in  this  area. 
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•  They  have  strong  links  with  Germany,  and  most  documents  and  meet- 
ings are  in  German.  They  are  due  to  have  a  meeting  shortly  to  review 
tfadr  in^^Eices  widi  Gennany  from  a  German  point  of  view. 

•  One  of  the  most  important  ingredients  for  success  is  to  have  a  strong 
champion  for  the  software  development  centre  in  the  parent 
organisation. 

•  Because  of  a  time  lag,  they  have  had  difficulties  in  the  past  with  mov- 
ing people  into  new  projects  sflwothly  as  old  projasts  come  to  fruition. 

•  They  also  originally  had  difficulty  because  people  didn't  have  suffi- 
cient ownership  of  the  products,  which  created  motivation  problems, 
but  greats  invd[v4»n«it  with  custosiiefs  and  planum  has  in^noved  this 
»tuati<m. 

•  They  would  like  to  develop  and  sell  their  own  products  in  the  U.K.,  but 

uttidde  to  add  head(x>unt  cm  their  own  initiatim  Psn  of  die  leascm 
ftn'  U.K.  prodiK^  is  to  have  custtm^rs  that  are  less  rranote. 

•  They  have  a  jdmt  devd^^mait  m&k  G^ramany  on  die  devel(^mait  of  a 
UNIX  kernel,  and  mm  have  lesposasitHlity  for  the  spooling  system,  the 
graphical  user  interface,  collage,  and  windows.  This  project  is  inte- 
grated with  the  decisions  being  made  in  Germany  and  the  code  is  open. 

•  The  German  side  does  not  like  having  a  split  kernel,  but  was  previously 
using  contractors  through  shortage  of  staff.  The  use  of  contractors  is 
now  stopped. 

•  Only  5%  of  problems  are  technical;  the  real  problems  are 
organisational  and  managerial,  which  is  the  reason  for  most  of  the 
travelling  to  Germany. 

•  Staffing  is  funded  out  of  Germany,  including  the  headcount,  hours,  and 
budget — all  of  which  are  covered  by  projects.  There  is  very  little 
flexibiHiy,  so  add^Hial  t^v^u  Imve  to  be  c^ioue^    extra  boun;, 
extra  heiuds  are  not  allowed,  and  tkuxc  is  month-by-month  tracking. 

•  Siemens  Woodley  has  lost  some  outstanding  people  through  frustration 
fixMn  fi||iting  die  QrgiuiisJtticm.  They  want  to  expand  faster  than  the 
^oent  ccHE^E^y  wants,  and  want  to  suj^it  Siemms  pic  in  die  U.K. 

•  Thote  are  major  problems  in  setting  up  a  small  outpost  of  a  very  large 
organisation  because  there  is  an  inevitable  inafCHr  difference  in  culture 
between  the  two.  Woodley  now  has  one  person  who  interfaces  with  the 
U.K.  parts  of  the  organisation  in  order  to  open  a  gateway. 
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•  Siemens  Woodley  has  additional  resources  from  work  students  who 
come  over  from  Germany.  These  industry  placements  tend  to  be  the 
best  students  frcMn  Gwrnany  (it  is  a  reward  to  ccnne  to  the  U.K.),  Aey 
are  ^llly  motivated  if  overqualified,  and  since  they  tend  to  work  for 
Siemens  every  holiday,  they  have  gcme  through  some  kind  of  inductioa 
process. 

•  They  have  mapped  their  grades  at  Woodley  onto  the  Siemens  manage- 
ment grades  of  0  to  4.  At  the  same  time,  they  have  developed  a  techni- 
cal path  of  consultancy  for  staff  without  management  skills.  However, 
lack  of  critical  mass  has  lol  to  difficulties  in  allocking  the  sorvices  of 
these  technical  experts. 

•  Tbey  Imve  al«>  created  narrower  bands  artificklly  in  die  pading  sys- 
tam  in  Older  to  give  people  son^  lei^rship  skills  development  early, 
before  group  and  team  leader.  A  grcnip  leader  will  be  respon^ble  for 
twenty  people  or  more. 

•  George  Brooke  as  manager  has  two  staff  functions — administration  and 
office  management.  Beneath  him  are  5  groups,  staffed  as  follows: 

Technical  Support  2 
Quality  Assurance  TQM  20 


•  George  Brooke  finds  that  German  engineers  are  solid,  reliable  and 
cle^,  but  diey  lack  in^riraticm.  British  engineers,  cm  the  Olim  haad,  are 
more  career-oriented,  even  above  the  conq)any,  and  th^  taid  to  be 
very  concerned  about  job  descriptions. 

•  Staff  appraisal  is  a  proems  of  the  individual  and  team  leader  in^)ai- 
dentiy  scoring  performance  with  a  form,  and  then  differoK^s  are 
discussed.  Appraisals  are  not  linked  to  salary  reviews. 

•  The  salary  review  process  is  changing.  Formerly  it  was  a  process  erf 
allocating  the  budget  across  salary  bands,  but  is  now  based  more  upon 
performance.  Some  ad-hoc  payments  have  been  made  for  extensive 
hours  but,  in  smne  cases,  hwm  wmi  d(Mie  without  bemg  D^imted,  so 
this  basis  has  been  rejected  as  unfair.  Now,  bonu£»s  depend  oa  bringing 
projects  in  within  budget 

•  Social  activities  have  included  wine  and  cheese  parties,  but  they  are 
now  short  of  space.  Siemens  has  a  sports  and  social  club,  but  the 
Woodley  staff  tended  not  to  fit  in  because  of  different  ages  and  inter- 
ests, so  they  have  a  small  social  fond  of  their  own  that  tt^y  keep  quiet 
about 
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•  A  major  problem  at  the  moment  is  the  splitting  of  the  centre  into  two 
sites.  Splitting  would  normally  be  a  problem,  but  has  been  exacerbated 
by  the  Nix&»f  acquisiti(m.  Hiey  had  fmmd  and  cho^  a  new  fxiikling 
but  have  been  forced  to  use  a  Nixdorf  building.  The  building  is  more 
remote  and  at  Bracknell,  which  is  unpopular;  the  facilities  are  bad;  and 
there  is  a  severe  cultiu-e  clash  between  marketing  people  in  smart  suits 
and  soitwwn  devetopefs  in  jeans.  Woifcra^  also  have  niggles  such  as 
having  to  work  in  an  open-plan  office  with  no  screens.  They  have  had 
one  resignation  already  and  are  expecting  more. 

•  They  have  had  some  conflicts  with  Gennany  over  quality.  Planners 
tend  not  to  be  interested  in  such  things  as  life  cycles,  and  they  have 
complained  about  the  quality  of  software  that  has  been  sent  over  from 
Ckimany.  This  has  led  to  some  managenHait-devetopmCTt  c<»ifixHita- 
ticms  and  ccmsequent  tn?eakdowns  in  confidence. 

•  Out  of  the  original  4  or  5  people,  two  have  survived.  Despite  the  best 
intentions,  it  is  (Ufficult  to  promote  internally  since  not  all  sti^  are 
capable  of  growing  with  the  job.  Also,  their  career  advancement  is 
limited  within  the  Woodley  part  of  the  organisation,  as  opposed  to 
within  Siemens  as  a  whole. 

•  It  might  be  useful  for  the  parties  to  this  bench-mark  to  discuss  commm 
recruiting  problems  and  the  salary  competition,  since  they  are  all 
filling  in  the  swat  small  pool. 
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Appendix:  Bell  Northern 
Research 


Structure  of  Meeting 

Bell  representative:  Mike  Turner 

An  introduction  by  Mike  Henry  on  the  concept  of  organisational  bench- 
marking. 

Back^und  of  participants 

A  M^^^mssicm  cm  Bell  Nortfaem's  interest  areas  and  its  attitudes  to  an 
iimninrat  group  noting  with  the  other  participants. 

•  Mike  Turner  spent  12  years  with  Plessey  and  Northern  Telecom,  before 
moving  to  Bell  NcHrtfaem  research,  fcsr  whc»n  hs  w<Hked  in  Canada  for 
three  aM  a  half  years. 

•  Bell  Northern  set  up  its  new  lab  in  Maidenhead  in        sai  Kfike  was 
one  of  the  main  project  managers  on  hardware  and  software  projects. 
Since  September  he  has  moved  into  human  resources. 

•  BdOi  NoTthem's  mm  competitors  are  AT&T,  PMtips,  Bcks^  and 
Sienwns. 

•  Bell  Northem  already  belongs  to  a  group  of  companies  that  discuss 
cfflnmon  is»i^      as  ^ikoi^.  Hie  otii»  iQ0id>ers  of  M&  g;mp  are 
British  Tdec<Hn,  GPT,  Mercury,  MotxKola,  Hewlett-Packard,  STC,  aai 
Philips. 

•  The  company  is  are  very  familiar  with  the  b^h-iMiMng  concept, 
particularly  with  regard  to  issues  such  as  human  resources. 
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•  Bell  Northern  has  its  own  phase  review  process  called  Bulk  Charge 
Supplement,  and  has  suffered  many  project  cancellations  as  a  result, 
aldiougfa  the  company  accepts  risk  as  part  of  the  business. 

•  Bell  Northern  is  not  sure  how  useful  the  group  meetings  could  be,  but 
is  prepared  to  try  them  and  see. 

•  Although  the  company  tends  to  think  it's  better  at  what  it  does  than  the 
competition,  it  accepts  that  there  are  lessons  to  be  learned. 

•  Bdl  Natthem  has  two  major  interest  areas — one  is  tite  n^stionship 
between  marketing  and  development,  and  the  oxh&c  is  career  develop- 
ment. 

•  The  company  is  currently  in  a  major  new  initiative  to  develop  a  dual 
career  path  for  software  engineers — a  management  path  and  a  technical 
leadership  path. 
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Appendix:  Original  List  of  Topics 


The  following  is  the  list  of  topics  that  was  developed  as  a  starting  point 
for  the  bench-mark.  The  list  was  amended  slightiy  since  there  was  sensi- 
tivity in  sotDR  cases  to  questicms  2.6  and  2.7. 

The  list  of  topics  is  divided  into  three  main  areas: 

Tbs  benefits  of  a  Eiux:^>ean  Software  Devel<^ment  Centre 

The  internal  organisation  of  a  European  Software  Development  Centre 

The  interactions  of  a  European  Software  Development  Centre  with  o^bia 
(H-ganisations 

Detailed  tqpics: 

1.  Whatfethepcrc^vedackiirfvaliieof  aEuK^^S^warcDevdc^ 
ment  Centre  from  the  p(»iit  of  view  of  the  client  /  parent  company 
managranent  /  local  management  departments  /  distributors? 

2.  What  triggered  tfc«  setting  up  of  tiie  European  Software  Devel<^ 
m^t  Centre  and  why? 

3.  Why  was  its  specific  location  chosen? 

4.  How  have  the  actual  boiefits  be«i  differeit  finom  Uie  origind  bea- 
efits  envisaged? 
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B  

The  Internal 
Organisation  of  a 
European  Software 
Development  Centre 


1.  Does  the  European  Software  Devel<q>inent  Centre  have  a  misaon 
statement  and,  if  so,  what  is  it? 

2.  What  are  the  goals? 

3.  How  is  the  organisation  structured  in  terms  of  functions, 
wrakgronps,  roles  and  respcm^bilities,  and  importing  relationships? 

4.  What  are  the  organisation's  dimensions  in  terms  of  number  of  staff, 
products  and  locations? 

5.  What  is  the  skills  matrix  of  the  organisation? 

6.  Wh^iesscmshiKvebeoa  learned  daring  the  setting  op  ai^ 
the  Eiirof)^  organisaticm? 

7.  What  software  performance  metrics  are  used — e.g.,  for  evaluating 
the  effectiveness  ci  die  software  development  process  and  the 
quality  of  output?  (e.g.,  number  of  lines  of  code  p«  pmcm-year, 
number  of  faults  per  line  of  code) 

8.  Recruiting  expectaticms  with  respect  to: 

-  Recruiting  of  experts 

-  Recruiting  to  train 

9.  How  long  did  it  take  to  set  up  the  European  Software  Development 
Centre,  and  what  is  the  process  and  culture  for  managing  change 
requirements? 


The  Interactions  of  a 
European  Software 
Development  C^tre 

Oipnkations 


1.  What  are  the  role  and  responsibilities  of  the  European  Software 
Development  Centre  with  re^>ect  to  the  partait  orpnisation? 

2.  What  are  the  interfaces  to  the  parent  organisation,  and  what  pro- 
cesses exist  for  intercommunication,  reporting,  information  sharing, 
etcetera? 

3.  How  is  fimding  and  budgeting  managed? 

4.  How  is     pafonxmnce  of  tite  European  Software  Develqpnarait 
Centte  raeasored? 

5.  What  commonality  of  design  development  and  support  proc^ses, 
and  developmrnt  tools/enviionni^nts,  exists  between  the  Euic^>ean 
and  parent  (H-ganisations? 
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6.  To  what  extent  is  there  interchange  of  staff  betwwn  the  European 
and  parent  organisations? 

7.  How  does  the  European  Software  Develqpn^t  C^tre  relate  to: 

-  End  users? 

-  Marketing? 

-  Sales? 

8.  What  are  the  roles  and  responsibilities  of  the  European  Software 
T>ev(A.optaem  Centre  relative  to: 

-  Pre-sales  support? 

-  Post-product  launch? 
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